When creating a new self-hosted runner for GitHub (enterprise), some default labels (Windows, X64, self-hosted) are automatically added. I can also add custom labels with the --labels parameter.
The thing is that I would like to reserve this runner for some specific workflows, but without restricting the repositories where it can be called. Because some projects use this default labels to choose runner, I would like to remove them.
I tried to find where this labels are created, but I'm fearing they are created server-side and that I would not have control over them...
Did anybody deal with a similar situation?
Thank you.
You cannot remove the default labels. If this runner is meant to be used exclusively by specific repos, then move them into a Runner Group and only allow that groups to be used by those repos.
No other way to configure that at the moment.
Related
I am planning to move from GitLab to GitHub and just started to experiment with GH Actions.
One thing I see is that I have to indicate that I want to run on a self-hosted runner for each job.
Is there a way to set a default for the Organization, or have it defined only once in the workflow YAML file?
I don't believe so. This is just another attribute that you need to consider when specifying a place for a job to run. For example, you already need to specify what type of system (e.g., OS and version) you want to use for each job via the runs-on directive, since there's no reasonable way to guess, so specifying self-hosted instead isn't exceptionally burdensome.
Anybody know if it is possible to pass in a repo name / base the build on a dynamic repo name? This would allow us to share the same build definition across different branches, cutting down on definitions when creating a feature branch, etc.
When using a TFVC repo we would store the different releases in the same repo but different paths. We could reuse the same build definition across different releases/FB's by altering the source path such as $/product/$(release)/......
It appears Git likes to have the repo hard-coded into the build (hence the dropdown - no way to plug in a variable.
While the question is targeted to On-prem Azure DevOps, if it is possible in the hosted environment it would be helpful to know.
I recommend using YAML build templates. By default these check out "self" and are stored in the repo. That way they work on forks, branches etc. Each branch can contain tweaks to the build process as well.
With the 'old' UI based builds this isn't possible.
What you are looking for is actually two things:
templates - this allows you reuse definition accross different pipelines
triggers - this allows you to trigger pipeline when commit happens on different branches
Looks like Task Groups solved the need (mostly). I was hoping to have one build definition that could be shared across multiple branches; while this appears to be possible on the hosted model, on prem is different.
I am able to clone a build (or use templates) to have an entry point into the repo/branch to get the sources, then pass off the work to a common task group. If I need to modify the build process for multiple branches, just modify the task group.
I inherited a project a while back that uses Azure DevOps Pipelines for deployment and when I want to edit the pipeline I have access to a wizard to walk through the tasks, triggers, variables, options, etc.. I then set up a completely separate project for a different organization and when I go to create a new pipelines it's only allowing me to use a YAML script. I don't see a way to run through the wizard.
Also, in the previous project under Pipelines I have sub menus for Pipelines and Environments. In the project I just set up I don't have these choices, only Builds. So it seems like I may be using an older version in the original project, I'm not sure and I can't seem to find a way to change the version.
Is this wizard no longer available for new projects? Is there a setting somewhere or something I am missing to gain access to it or do I have to use YAML only from this point on? If that is the case, is there a way to upgrade the old project to this version (I want to stay consistent)?
Is this wizard no longer available for new projects?
No, you just facing the different design of azure devops.
You can only create the YAML.
The page you can see the tasks, triggers or other tabs is the design of Classic editor pipeline.
Please choose Use the classic editor after you new pipeline.
Click Continue after select the source (the repository and the branch) for your project.
At the next step, you can choose Empty job, also you can add some tasks.
Note: do not select Configure as code. It is YAML.
Now, you can see the tabs like tasks, variables, triggers and etc.
Could not seen Pipelines and Environments.
These two tabs are the new UI design which published in recent sprints. And we provide it by enable Multi-stage pipelines in
Preview features panel.
I assume you did not enable this feature and just saw Builds there.
Click your head account which located in right corner, then choose Preview features:
Then enable Multi-stage pipelines.
After enable it and close the panel, this page will be re-load automatically. Then you will see Pipelines and Environments in the left wizard panel.
Our main project is hosted and managed on VSTS online. We are managing the work using Features, User Stories and tasks. In addition, the code is managed and stored in Repos. We are working with pipelines and such for CICD. Last, we installed some extensions downloaded from the marketplace.
Currently, we are running on the build-in Agile process. We would like to create an inherit process and move the project to it. I’ve done that in the past but without the project using CICD.
The question is, can we do that safely without harming or endangering our code and CICD operations?
Thanks
The CI/CD processes not related to the Work Item process. you can move to inherited process template without harming or endangering your code and your CI/CD pipelines.
Unless you touch the work items during the build (with custom scripts/API) and change fields etc. so you need to update the scripts (e.g. you change a field called "A" and in the new template is "B").
I'm using Visual Studio Team Services and I'm trying to set up Release Management to allow automated deployments for our Azure Web App to multiple environments. I would like the same source to be deployed to each environment, but with modified configuration settings.
I was hoping that I could create a single Build for my application, and then modify the configuration at deployment time for each environment. I'm aware that this can be done for appSettings and connectionStrings (either through Tokenization, or even managing those settings via the Azure portal), but I'd like to be able to make more general changes to the web.config file. For example, I want to be able to:
Update 'simple' settings such as appSettings/connectionStrings
Update multiple attributes on elements (like httpErrors)
Insert or rewrite sections of the config file itself (for example to add IIS rewrite rules, or to remove unwanted HTTP handlers for production)
Currently we achieve this by using config file transformations and separate publish profiles for each environment (manual deployment). I can't see a way to re-use this if I want a single release pipeline.
I'm hoping someone can help point me in the right direction. I'm also happy to accept alternative solutions - ultimately I just want to be able to deploy the same source (e.g. from the same commit in source control) to multiple environments, with different configuration, while keeping some kind of flow from dev, to test, to eventually production.
You can use Tokenization Task to update the files base on the environment variables.
More similar extensions: Replace Tokens and Colin's ALM Corner Build & Release Tools.