Set up lighthouse artifact feed for our fork #13
Conversation
Visit "https://feeds.dev.azure.com/${YOUR_ORGANIZATION_HERE}/_apis/packaging/feeds" to find the "fullyQualifiedId" of your organization's default artifact feed. That value is what you should set the "ARTIFACT_FEED" environment variable to in Azure DevOps UI. (IDs are formatted like this: "af6c77da-ef34-bcde-daaf-e2b489a23b2c") The "description" for the feed should say "Default feed for ${organization}", e.g. "Default feed for atomcommunity". If the description says something else, or "null", then it's the wrong feed.
|
Reminder to find our Azure DevOps organization's default feed id from here: https://feeds.dev.azure.com/atomcommunity/_apis/packaging/feeds (Next to And either set it as the value for an environment variable
|
|
Also, as mentioned in #10 and #11, we are looking at the official Cache task, which is officially supported by Azure DevOps, as opposed to the Lighthouse Universal Packages/artifact feeds solution, which is an unofficial "DevLabs" project. microsoft/azure-pipelines-artifact-caching-tasks#40 (comment) This is a good thing to get working first, though. |
Where can I find this feed ID? |
Visit this URL in a browser where you are logged into Azure DevOps: https://feeds.dev.azure.com/atomcommunity/_apis/packaging/feeds This page serves a json structured data file. In it there should be a If you have more than one (Their server will apparently check your cookies/web session with Azure DevOps to make sure you are an authorized administrator for the "atomcommunity" Azure DevOps organization. When I try to visit this page, it shows the following error: (Maybe this is too much of an explanation, but I hope to make it very clear for anyone else who might be reading this and hoping to understand how to set up Azure DevOps.) |
|
By the way: I am working on a total replacement for the Lighthouse caching thing. Seems promising so far, but I can't say for 100% sure that it will work: Similar idea to #11 |
|
I added the ID. Let's see how this runs. |
aminya
force-pushed
the
master
branch
2 times, most recently
from
7a81062
to
9755960
Compare
|
I merged this to test it on master. |
Requirements for Contributing a Bug Fix
Identify the Bug
#1 (comment)
#11 (comment)
Description of the Change
Rather than hard-coding upstream Atom's feed ID, set it with an environment variable. We can configure this in Azure DevOps so that our environment variable points to our fork's (technically our Azure DevOps oganization's) artifact feed.
Having this artifact feed set up properly can save about 10 minutes per OS.
Alternate Designs
Just hard-code our ID in place of upstream's.
We could also make separate
.ymlconfig files for our CI entirely I guess, and stop using the original ones. This avoids the possibility of merge conflicts. But I think that's not worth the hassle and the mess of files it would make. Upstream ahrdly ever updates their CI config, and I think we would likely want to track their changes if they do.Possible Drawbacks
Some people don't like to save time. (Just kidding).
I guess with caching you have to make sure it updated when you want it to. So keep an eye out that it doesn't restore a cache when it shouldn't (i.e. when something in the repo changed and
node_modulesneeds to be rebuilt).Verification Process
Successful node_modules restoration on my personal fork: https://dev.azure.com/DeeDeeG/b/_build/results?buildId=67&view=logs&j=4fbced83-508e-5fe0-c978-5c71ec0fc506&t=96ecc7f1-cdb5-518e-2cb8-d9226cce9313
Release Notes
N/A