If we use the UI of build pipeline, we see 'enable system diagnostics' check box as given below. There is also a default variable 'system.debug'.
What is the difference between these two?
One comment here states both could be the same. But if we set system.debug is set to 'true' 'enable system diagnostics' is still unchecked.
They both are the same. It is given here. The main purpose is to set the variable for automated runs. But it can be used for single runs too, which makes the UI checkbox, the additional duplicate feature, pointless.
It is confusing because it appears in build pipeline and not in release pipeline. Also when we run , like you said, even when the variable is set to true, the UI is still not updated(unchecked). Which might require double work(checking diagnostics too) like I did for some time.
"To configure verbose logs for all runs, you can add a variable named system.debug and set its value to true." And ignore the UI check box
Related
In Gitlab ci We have declared our variables like below
USER_NAME:
value: ""
description: "Enter Username"
File_Name:
description: "Enter the file name"
It only give a text box where We can enter the value.
Can I make a drop down select box is there any option available to make it a select box.Then we can select the value from drop down.
GitLab 15.7 (December 2022) has finally implemented this:
Select predefined CI/CD variables values from a dropdown list
Previously, you could pre-fill CI/CD variables in the “Run pipeline” page, with a specific value.
Unfortunately, if you had multiple options for the variable’s value, you still had to manually input the option you wanted. This was an error-prone process because you could easily input an invalid value, or just mistype it.
In this release, we’ve added the ability to set a list of values which are surfaced in a drop-down list in the “Run pipeline” page.
Now you can define the exact list of values that are valid for each CI/CD variable when running a pipeline manually, greatly simplifying your workflow when using manually-triggered pipelines.
See Documentation and Issue.
No it is not possible. What we ended up doing, if we want to have a better configurable way, was using the gitlab pages with a form, which will use the API or a POST to create a new pipeline. This way we are quiet flexible with the options to provide to the users.
I see an active proposal for it https://gitlab.com/gitlab-org/gitlab/-/issues/29159 (almost 2 years). But no activity for the moment.
It's not possible yet
Backend ticket is created for it May 19, 2022
https://gitlab.com/gitlab-org/gitlab/-/issues/362934
Original proposal https://gitlab.com/gitlab-org/gitlab/-/issues/29159
I am creating a new pipeline for deploy multiple apps in azure devops, for sample:
I wanna make xml variable substitution for sample ConnectionString in web.config.
For sample:
But variables only can group by scope Stage and not by task in same stage, can I do this somehow?
Thanks in advance.
It is not supported to definite variables with the same name in same stage but different tasks. The document has mentioned the scopes of variables.
Custom variables can be defined at various scopes.
Share values across all of the definitions in a project by using
variable groups. Choose a variable group when you need to use the same
values across all the definitions, stages, and tasks in a project, and
you want to be able to change the values in a single place. You define
and manage variable groups in the Library tab.
Share values across all of the stages by using release pipeline
variables. Choose a release pipeline variable when you need to use the
same value across all the stages and tasks in the release pipeline,
and you want to be able to change the value in a single place. You
define and manage these variables in the Variables tab in a release
pipeline. In the Pipeline Variables page, open the Scope drop-down
list and select "Release". By default, when you add a variable, it is
set to Release scope.
Share values across all of the tasks within one specific stage by
using stage variables. Use a stage-level variable for values that vary
from stage to stage (and are the same for all the tasks in an stage).
You define and manage these variables in the Variables tab of a
release pipeline. In the Pipeline Variables page, open the Scope
drop-down list and select the required stage. When you add a variable,
set the Scope to the appropriate environment.
This maybe a workaroud to change the value of variable after one task.
Please refer to this issue: How to modify Azure DevOps release definition variable from a release task?
I want to understand Github Checks API so that I can use them to retrieve data. On following Github documentation https://docs.github.com/en/rest/guides/getting-started-with-the-checks-api I am able to derive that check runs are associated with the sha of the change and at each commit on branch check suite is created. Checks API helps in getting all this information. But I want more clarity on three of them in terms of differences. Can anyone please explain these three terms using simple example and terms?
So, first of all, the GitHub Commit Statuses API is separate from the GitHub
Checks API (includes suites & runs), so let's look at them individually first then I'll explain the differences.
Before we get into it, I want to differentiate a PR Check from a Check Run, to avoid confusion. A PR Check describes the current state (trying not to say status here 😉) of a given job or task running in CI or elsewhere on a specific PR commit. These can be created via either a Commit Status or a Check Run. All the items in the pink box below are PR Checks, notice the Hide all checks button.
GitHub statuses - API
I see this as the simple, all-purpose API for reporting PR Checks for a given commit. It's easy and doesn't require jumping through hoops to just display a simple result of a PR Check for a given commit. This API also came before the check API so it's a little less powerful.
Pros
Simple and easy API
Simple relation with context as the identifier.
Can have a fully customizable text description on the PR Checks UI.
You can create statuses as a user with a Personal Access Token (aka PAT) without needing to create a GitHub App, though does work with GitHub Apps too!
Cons
Limited status options, only allow error, failure, pending, success, no conclusion subset option to define completed jobs like Check Runs.
No concept of job timing or duration.
No grouping of statuses, like Check Runs are grouped into Check Suites by their GitHub App
No annotations
No detailed output logs. This is not too important as you could just link to the URL where the actual PR Check was run such as in CircleCI, Jenkins, etc. But the user is not always authorized to view these runs so the output could be helpful for open source repos that have non-public CI.
GitHub Checks - API
The Checks API is the latest and greatest tool for displaying task results on commits, which can essentially do everything the Commit Statuses API can do and more. Check Runs belong to one Check Suite, one Check Suite can have many Check Runs. You can only have one Check suite per commit (i.e. head_sha) per GitHub App, attempting to create another for a given App will just return the previously created Check Suite. Thus, a new Check Run is automatically assigned to the Check Suite based on the authenticated GitHub App, you cannot manually assign Run to Suites.
Contrary to statuses, Check runs are identified by an auto-generated check_run_id and not a context string.
I haven't touched too much on the Check Suites API because they are really just a grouping of Check Runs which is pretty self-explanatory and they don't affect any of the PR Checks UI, only the grouping of Check Runs in the checks tab. One thing to note is that by default you can create a Check Run without having to first create a Check suite and GitHub will just create a new Check Suite for you.
Pros
Greater granularity of status/conclusion for a run.
A lot of power to display the result of a PR Check.
Can provide run context via output summary in Markdown.
Can create annotations for specific lines of code to add information about the analysis performed, like linting error for a given line of code. These will show up in the PR files tab UI similar to PR code comments as well as in the PR Checks tab with any other Check Run output.
Has time awareness to report on durations automatically with little effort.
Cons
A little more complicated API and relationships to manage.
Part of the description in the PR UI is auto-generated based on the status conclusion and duration of the check run task.
Cannot be created via a user PAT, must be created from an authenticated GitHub App. Read access to this API does not require authenticating as a GitHub App.
One edge case you likely won't come across but is good to know: If you are creating a new Check Run with the exact same name of an existing check run under the same authenticated app. The resulting behavior is a little strange but doing this will create the new Check Run under the same name, but will not delete the existing Check Run. However, the Check Suite will not see or link to the existing Check Run, even in the PR UI. BUT!! If you change the name of either such that the runs now have unique names, it will be linked up again. It seems GitHub just does a sort by date and then filters by unique names when looking up Check Runs in a Check Suite. This does not apply with identical names from different authenticated apps.
Comparisons
Below is a mapping of sorts to compare similar options between the Commit Statuses API and the Check Runs API. They are not exactly 1:1 but similar.
Commit Status
Check Run
Option Desciption
sha
head_sha
These are equivalent with the minor exception that the Commit Status is linked to the sha directly, whereas the head_sha is linked to the Check Suite that the Check Run belongs to.
context
name
The context is used as an identifier but both define the title of the PR Check in the PR UI. Because Check Runs are tracked by the check_run_id the name option may change without creating a new Check Run. This is not the case for context, changing the context will always create a new Commit Status. You may not have duplicate names for Check Runs created with the same GitHub App, see note above.
context*
external_id
The external_id is meant for keeping track of Check Runs without having to store ids or always keep the name constant. This is only somewhat similar to the context option but only for the purpose of identifying the Check Run.
description
output.title
The main difference here is that description gives you the full space to work with, where output.title will be displayed after the auto-generated status string.
target_url
details_url
These are somewhat equivalent, the first difference is that target_url will not show unless defined whereas details_url will default to the check run URL in the PR UI. The other difference is the Check Runs Details button on the PR Checks UI will always link the the Checks page which will present a link to the details_url if defined.
state
status
These are very similar but have slightly different allowed values but effectively appear the same in the PR UI.
N/A
conclusion
This just shows the increased power of the PR Checks API where you have more granular control over the PR Check status, though not a big difference in the UI, see example variations below.
N/A
started_at
No comparable option for Commit Statuses.
N/A
completed_at
No comparable option for Commit Statuses.
N/A
actions
No comparable option for Commit Statuses.
N/A
output
No comparable option for Commit Statuses.
N/A
output.annotations
No comparable option for Commit Statuses.
* Only somewhat similar, not a direct equivalent.
PR Checks UI Component mappings
I've taken a simple PR Check and highlighted the differences between the elements of the UI between the Commit Status API and the Check Runs API. Very similar but slight differences.
Below are example variations to relate the options to their impact on the
PR Checks UI.
Commit status variations
Check Run variations
If a check run is in an incomplete state for more than 14 days, then the Check Run's conclusion becomes stale. Only GitHub can mark Check Runs as stale.
Checks Tab in PR UI
The Checks Tab in the PR UI will display all created Check Suites and their child Check Runs and allows you to set the output option to control the content of this page. This page would also show images and annotations if you defined those too.
One final note: You cannot DELETE any Commit Status, Check Run or Check Suite once created, only updating is allowed. With these statuses being so ephemeral this is not that big of a deal but in case you were wondering.
Update (6/21/2022)
I found two more quirks to explain. First, the details_url for Check Runs does not set the value of the Details button, instead the Details button actually always redirects to the Checks page which has a link to the details_url if defined.
Second, once a Check Run status is set to 'completed', there is not way to un-complete the Check run. But you can get around this by creating a new Check Run with the same name and set that status to something other than 'completed'. See this edge case with duplicate-named Check Runs explained above in detail.
Update (6/29/2022)
As mentioned above, the Check Runs API keeps track of the duration of the run. It is important to note that the started_at time is set only once whenever a check run is created, regardless of the defined status. For example, if I trigger a CI build and set all jobs status to queued, the jobs run duration will be inaccurate. A good way to fix this is to always set the started_at time whenever you set the status to in_progress. Something as simple as const started_at = new Date().toISOString() (javascript) will do the trick.
When I create a new record on the Service Request (SR) application (Maximo 7.6), I would like to set the required Reported Date (SR.REPORTDATE) field blank. Before save action, the user will input data into that field. I wonder how this could be done?
Thanks for the help.
If you look in Database Configuration to see if REPORTDATE has a Default Value, I think you'll find &SYSDATE& in there. If I'm right, then you can delete that default value, save your changes, and apply your changes. Otherwise, you'll need to do as #Dex suggested.
My mind immediately goes to an automation script. A default value control or the default value setting in Database Configuration may work too and is recommended before a script if you have the expertise to confirm or deny this theory.
As for the automation script, I think you can create one with an object launch point on SR on the "add" event. The script would simply set that field to null, which shouldn't change the "required" flag either, so the rest of your needs will still be met.
mbo.setValueNull("REPORTDATE");
I've built a Custom Plugin for CRM 2011. Basically, the same plug-in has been deployed in two different environments: Test and Pro.
These environments are obviously twins. Same entities, same configurations etc..
The plug-in, triggers on update of a specific boolean field. On true value, triggers and add a contact to a list. So, with the same logic, on the same field set on false, triggers and remove the contact from the list.
Now, on "test environments", it triggers on both situations. But on "Pro environments" , when the boolean field it's set on false, it doesn't trigger!
I discard any supposition of a logic bug implementation. For the reason that it works well on the the first environment.
Above, it doesn't write any log in this case. And it makes me more convinced that it doesn't trigger at all.
Does anybody knows , what could be the problem?
First, make absolutely sure that your theory is correct. Throw an Exception right at the top of your plugin, and see if you get the Exception pop-up in CRM on both True/False. If you do, then the plugin is firing on both a True/False update and there is something wrong with your code - I can't imagine what it is since it works in dev, but at least you've proven that it isn't the CRM plugin infrastructure's fault.
If you don't get the pop-up Exception for the False scenario, the only other possible answer is that CRM's plugin infrastructure doesn't think that field should be updated. When the screen refreshes after an update to False, does that field still show False or does it go back to True? It is possible to "cancel" a field update by removing it from the field list of the entity that gets passed into your Pre-Operation plugin - is it possible there are other plugins that execute before this one and maybe cancel that field update?
Last thing I can think of: you are saying Update but do you mean Create? If that boolean field's default value is set to False in Prod but not in Dev, when you create the entity, that field won't be included in the field update list (and thus not fire your plugin) if it is set to False because the system already knows the default value to use on a Create is False.